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(57) Abstract 

AuthcnticaUon by an intcimcdiaiy F (e.g. a bank) of an originator C of a message (e.g. a client sending an instrucUon to pay a 
merchant M) is accomplished using a protocol which does not require the intcnnediary to possess P^'^^^'^^^^^'yj^';^^^^^^ 
the merchant M to protect the contents of the message. Furthermore, the protocol docs not rtquue any party to the transaction to decrypt 
any value previously encrypted by any other party, so a reversible encryption algonthm is not required. 
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Mpthnd<: and apparatng fnr anthpntiraring an n nginarnr nf a mp<:<tagp 
Tftrhniral PiplH 

This invention relates to methods and apparatus for authenticating an originator of 
5 a message, and which in particular enable the originator of a message to be authenticated 
without the need for specialized authentication organizations, and without decryption of 
encrypted information. 

RarVgrniinH Ar^ 

10 Modem computing and telecommunication systems have enabled a rapid and 

continuing increase in exchange of information between individuals and organizations, e.g. 
via the system commonly known as the Internet. However, the full potential of such 
systems is currently restricted by the difficulty of providing secure transfer of valuable 
information over the system. Many organizations would like to use publically-accessible 

15 networks for conducting various transactions, such as the sale of goods and services. In 
principle payment for such u^sactions could be obtained from a customer by transfer over 
the network of relevant information such as credit card details. However it is clearly 
possible for a dishonest third party to intercept such information during transmission, and 
then mis-use it to the third party's financial advantage. Various other fraudulent activities 

20 are possible, such as false repudiation of orders. Accordingly most transactions which may 
be initiated over a network still have to be completed using conventional methods such as 
exchange of paper invoices and payments or voice messages, using more trusted systems 
such as mail or voice telephone networks. 

It is essential for an effective electronic transaction mechanism to have several 

25 properties: 

- authentication (i.e. confirmation of origin) of messages involved in a transaction; 

- protection of the integrity of messages involved in the transaction, and ability to prove if 
a message has been corrupted; 

- prevention of false repudiation of an agreement to make a payment; 

30 - prevention of frauds involving recording and replaying of messages involved in a 
transaction; 

- economy of implementation; and 

- compatibility with national security interests. 

Various proposals have been made for electronic message authentication. Although 
35 they tend to satisfy the primarily technical requirements, they also tend to be either costly 
and/or contrary to national security interests. Thus many proposals involve reliance on a 
specialized third-party security service, for example for authentication of messages in each 
transaction or to supply and certify public encryption keys. In addition many of these 
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proposals involve the use of reversible encryption algorithms, i.e. algorithms in which 
information is concealed by encryption by a sender and retrieved again by decryption by 
the recipient. Such algorithms can also be used for transfer of other information which is 
contrary to national security interests, so the distribution and in particular export from 
5 some countries of products which incorporate reversible encryption algorithms is often 
controlled or prohibited. Any proposal which involves decryption, and thus requires a 
reversible encryption algorithm, is unlikely to be suitable to be made available for use on 
a widespread basis. 

It is an object of this invention to provide a method and qjparatus for authenticating 
10 messages which avoids the problems entailed in prior proposals, and in particular does not 
require any specialist security service nor involve the use of a reversible encryption 
technique. 



Disclosure of Invention 

15 According to one aspect of this invention there is provided a method for enabling 

authentication of an originator of a message, using a composite one-way function which 
enables a protected version of an input value to be derived by applying successively in 
either order two component one-way functions using two respective values, but which does 
not enable the input value to be readily determined from the protected version in 

20 combination with either of said values individuaUy, comprising the steps of: 

a) receiving a protected version of a password, said protected version being derived 
from a first of said component one-way functions using said password as said respective 
value; 

b) generating another value; 

25 c) generating a protected version of said other value by applying a second of said 
component one-way functions; 

d) generating a digital signature for the protected version of said other value; 

e) applying said second component one-way function using said other value to said 
protected password to derive a ticket key; 

30 0 generating a session key; 

g) protecting said session key with said ticket key; 

h) supplying said protected version of said other value, said digital signature and said 
protected session key to the source of said protected password; and 

i) thereafter destroying said other value, said ticket key and said session key. 

35 According to one aspect of this invention there is provided apparatus for enabling 

authentication of an originator of a message, using a composite one-way function which 
enables a protected version of an input value to be derived by applying successively in 
^ either order two component one-way functions using two respective values, but which does 
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not enable the input value to be readily determined from the protected version in 
combination with either of said values individually, comprising: 

means for receiving a protected version of a password, said protected version being 
derived from a first of said component one-way functions using said password as said 
5 respective value; 

means for generating another value; 

means for generating a protected version of said other value by applying a second 
of said component one-way functions; 

means for generating a digital signature for the protected version of said other 

10 value; 

means for applying said second component one-way function using said other value 
to said protected password to derive a ticket key; 

means for generating a session key; 

means for protecting said session key with said ticket key; 
15 means for supplying said protected version of said other value, said digital 

signature and said protected session key to the source of said protected password. 

Brief Descriprinn of DrawjT^g^ 

Methods and apparatus for authenticating an originator of a message in accordance 
20 with this invention without the use of a reversible encryption algorithm will now be 
described, by way of example, with reference to the accompanying drawings, in which: 
Figure 1 illustrates a transaction in which authentication of messages is 
necessary; 

Figure 2 is a block schematic diagram showing the transfer of messages in a 
25 protocol by which a trusted intermediary F enables two parties C 

and M to authenticate each other, and verifies that C has authorized 

a transaction; and 
Figures 3a-c show successive stages of the protocol. 

30 Best Mode for Carrving Out the Invention. & Industria l Applicability 

Referring to Figure 1, the invention wUl be described by reference to the example 
of a client 10 who wishes to instruct a financial intermediary 12 (such as a bank or credit 
card company) to make a payment to the account of a merchant 14. Each of these parties 
possesses a protocol unit C, F and M respectively, comprising for example appropriately- 

35 programmed computers (as in the case of the client 10 and the financial intermediary 12) 
or special-purpose hardware devices (as in the case of the merchant 14), These units are 
coupled to a communication system 16 which comprises multiple computer networks 18 
interconnected by routers 20 and which typically serves many tens of thousands of users. 
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The networks 18 are of the kind in which at least some units attached to one network 18 
can monitor messages travelling over that network between other units on the same or 
other networks 18. Accordingly it is not safe to transfer information such as financial 
transaction details in clear form over the system 16 in view of the risk of interception and 

5 misuse of that information by other parties. Furthermore, the large number of people and 
organizations connected to the system 16 means that for any given transaction the parties 
involved may never have previously had any contact. Accordingly they do not necessarily 
have any established reladonship by means of which they might confirm each other* s 
identity and trustworthiness. Even if such a relationship does exist there remains the risk 

10 of a fraudster masquerading as one of the parties in order to defraud the other. 

The present invention provides a protocol by which the parties to a transaction, for 
example, can authenticate messages (i.e. confirm the origin of the messages) involved in 
the transaction. The method does not require the parties to share any information which 
one party must encode and the other must decode, for example to confirm identity; thus 

15 there is no need for a reversible encryption algorithm to be used. Although the method 
does entail the participation of a trusted intermediary, many existing transactions typically 
involve the participation of such an intermediary in the form of a financial institution, in 
which trust is placed, so this requirement should not normaUy constitute an obstacle. 
Furthermore the intermediary does not have to hold secret information belonging to either 

20 party. 

The protocol involves the use of an arithmetic operation known as modular 
exponentiation, in which a first number a is raised to some power p, and this value is 
divided by a second number j3; the desired result q is the remainder of the division 
operation: 

25 q = aP mod j5 (1) 

Modular exponentiation is a one-way function, in that although the operation of equation 
(1) is straightforward to perform, the inverse operation, i.e. determination ofp given a, 
0 and can be made extremely hard by appropriate choice of the values of a and /3. & 
is chosen to satisfy the condition 

30 0 = 2i + 1 (2) 

where / is a prime number, a is typically chosen to be a value which is a 'generator 
modulo iS', meaning that the value of (a** mod ff) varies through aU values between 1 and 
&A as p varies between 1 and j3-l. Pairs of values a, /3 can be selected so that 0 
conforms to equation (2), for example using the method described in Applied Cryptography 

35 by B. Schneier, John Wiley & Sons, 1994, pp. 208-9. 

Referring to Figure 2, it is first necessary for the client 10 and the merchant 14 to 
select respective passwords Pc and P„, and for these to be notified in encoded form to the 
financial intermediary 12 once only prior to the first transaction. To tiiis end the financial 
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intermediary's protocol unit F selects pain of numbers a^* 0^ &m ^ described 

above, stores them for future use as described below, and informs the client's protocol unit 

C and the merchant's protocol unit M respectively of the values of these pairs, as indicated 

by dashed lines 22 and 24. No particular secrecy or security is required for this step. 
5 Thus the values may be sent in printed form by mail, and entered into the protocol units 

via a keyboard, magnetic stripe card or the like. The client 10 selects a password (e.g. 

an easily memorized word, number, etc.) and enters this into the protocol unit C as well. 

The unit C manipulates this password in a predetermined manner to convert it to purely 

digital form if necessary and ensure the resulting value is in one of the ranges [3, i-1] 
10 and [i+1, )S,-2], where i satisfies the relation ^,=2i+l, so that the value of is relatively 

prime to /S^-l. The digital password P^ is then encoded by hashing it using equation (1) 

and the numbers a^, jS^ supplied by the financial intermediary 12 

Ep, = a.^^ mod )3e (3) 

If desired, to decrease vulnerability to guessing etc. of the client's selected password by 
IS another person, the digital password P^ may be concatenated with a random 'salt' value s 

before encoding, as described in Unix operating system security by F.T. Grampp and R.H. 

Morris, AT&T Bell Laboratories Technical Journal, 63, October 1984. In this case the 

encoding operation is 

Ep, = a,^ mod Oa) 
20 The encoded value is communicated to the financial intermediary 12 by the client's 
protocol unit C, as indicated by dashed line 26, taking reasonable precautions to verify the 
association of the value of Er^ client. 

In order to implement and coordinate these functions the client's protocol unit C 
includes a controller 30 coupled to an exponentiation unit 32, and a module 34 for deriving 
25 the digital password P^ from the client's password and for supplying it to the 
exponentiation unit. This unit is arranged to perform the calculation 

a'' mod )3c (4) 
on any value a, including supplied to it by the controller 30, and to furnish the result 
of this calculation to the controller. For security purposes the storage module 34 and the 
30 exponentiation unit 32 are designed never to output the value of the password P, directly, 
as indicated schematically by the enclosure 36 around them. The values a„ and s (if 
used) may be concatenated for storage purposes to make misuse by another person of the 
values as stored more difficult. 

The merchant likewise selects a password and enters it into the protocol unit M (for 
35 example using a smart card which is accessible to the merchant's staff). The unit M 
derives a corresponding digital password P„, encodes it using the numbers a^, )3„ 
according to the relation 

Ep^ = a^^ mod e„ (5) 
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and communicates the value to the financial intermediary 12 in confidence, as 
indicated by the dashed line 28. The merchant's protocol unit includes a controller 40, 
exponentiation unit 42, storage module 44 and enclosure 46 corresponding to the items 30 
to 36 in the client's unit C. 
5 Referring to Figures 3a to 3c, in a first stage 100 of the protocol, the client 10 

composes an appropriate message, such as "transfer five hundred dollars from my account 
no. 1234 5678 9876 to M's account no. 9876 5432 1234" and liters it into her protocol 
unit C. As a preliminary step to deriving a digital signature which incorporates the client's 
password and which will accompany this message, the controller 30 in the unit 10 then 
10 generates two numbers n^, n^u the values of these numbers may or may not be selected 
essentially at random (although with the restriction noted below in the case of Hd), but the 
controller 30 is arranged to ensure that each value used is chosen afresh, for each 
transaction, in a manner which makes it unlikely that anyone else can predict the value 
chosen and unlikely that the same value will be chosen for two different transactions. As 
15 they are used on a single occasion the numbers nc, n^ are referred to as 'nonces'. 

The controller 30 concatenates the nonce n^i with a digital representation R of the 
characters comprising the client's message, and encodes the resulting sequence of digits 
using a one-way hashing fimction (such as the MD5 function described in The MD5 
message digest algorithm by R.L. Rivest, Internet RFC 1321, April 1992) to produce a 
20 fixed-length sequence of digits represented herein as H(nci, R). where H is the hashing 
fimction. The unit C includes an MD5 encoder 38 coupled to the controller 30 for 
effecting this hashing function. The value of n^^ is selected by the controller 30 so that 
H(nci, R) is a generator modulo 0^, in the same manner as described above in respect of 
the number a. Selection of n^, in this way makes it hard to discover the value of H(nc,, 
25 R) from the password-protected version (described below) which will actually be 
transmitted. The use of the hashing fimction H has the effect of compressing the size of 
the digital value involved, thereby facilitating subsequent calculations, and itself makes 
decoding computationally infeasible. The values of n^i and thus of H(nci, R) play a 
significant role in the final verification of the client's digital signature, so it is important 
30 that they are protected at this stage. 

The hashed value Kin^u R) is itself password-protected by the controller 30 by 
supplying it as the input value a to the exponentiation unit 32, in order to derive the 
client's digital signature for the message R according to the relation: 

Sc = {(H(n,„ W mod 0,} (6) 
35 The protocol unit C then sends the message R, the nonce n, and the signature Sc to the 
merchant's protocol unit M through the communication system 16, as indicated in Figure 
2 by the message transfer labelled 1 . 

In the next stage 102 (Figure 3a) of the protocol, the contfoUer 40 in the protocol 
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unit M itself selects a nonce n„ for this transaction, and forwards it to the financial 
intermediary's protocol unit F, together with the message R, the nonce n^ and the signature 
Sc received from the protocol unit C. This is indicated in Figure 2 by the message transfer 
labelled 2; the items R, ne and the signature Sc are enclosed in square brackets [ ] to 
5 indicate that these values are not generated or re-calculated by the protocol unit M, but are 
simply forwarded as received. 

When these items are received by the protocol unit F, it undertakes a series of steps 
comprising stage 104 (Figure 3a) of the protocol. To this end the protocol unit F includes 
a controller 50 coupled to an exponentiation unit S2 in a secure enclosure 56 in similar 
10 manner to the client's unit C. The secure enclosure 56 also contains a session key 
generator 60 for producing random number keys and supplying them to the controller 50; 
since the security of these session keys is important, the controller 50 itself is located in 
a secure enclosure 62. This enclosure 62 also contains an MD5 encoder 58 corresponding 
to the encoder 38 in the client's unit C. 
15 The steps performed in stage 104 are as follows: 

(i) Generate two nonces u and v for use once only for this purpose, in the ranges 

[3, i-1] and [i+1, i3,-2] for w 
[3.j-l] and0+l./5m-2]forv 
where / satisfies the relation j3,=2i+l and j satisfies the relation /3n=2j + l. 
20 (ii) Compute two keys, again for use once only for the present transaction, one key K^f 
being used by the client's unit C and the financial intermediary's unit F, and the other key 
being used by the merchant's unit M and the financial intermediary's unit F; these 
keys are derived by the controller 50 according to the relations: 

= (E^r mod i3, (7) 
25 K^^ (E,J^ mod /3„ (8) 

It should be noted that the right-hand side of equation 7 can be expanded into the form 

(a,'^ mod /3J" mod ft (9) 
and that, because modular exponentiation is commutative 

= (a,^ mod )SJ» mod ft = (o,» mod ft)*^ mod ft (10) 
30 Thus if the client's protocol unit C is provided with the value E^, = (a," mod ft), which 
can be readily done without risking revealing the value of u, then the controller 30 can set 
a equal to this value and compute the value of the key Kef using formula (4) above. 
Equation (10) in effect defines a composite one-way function, comprising a first component 
one-way function (a/^ mod ft) using the password P^, and a second component one-way 
35 ftjnction ((EpJ" mod using the value w. The merchant's protocol unit M can likewise 
compute the value of the key from the formula (EJ)^ mod /3„ where Ey = 
(a„" mod j3J. 

(iii) Compute the values E^, and Ey, using the number pairs o^, jS^ <^m^ which 
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the unit F originally selected, and the values u and v generated at step (i). 

(iv) Obtain a random number from the session key generator 60 for use as a session key 
which will be made known to both the client's protocol unit C and the merchant's unit 

M, and communicated by each unit to the other to verify the sending unit's identity. To 
5 protect the session key itself, the controller 50 generates two encoding keys, one for the 
unit C and one for the unit M, using the hashing function provided by MD5 encoder 58, 
and combines the session key with these keys to produce two tickets by a bitwise 
exclusive-OR PCOR) operation, represented by © in the following relationships: 

ticket for C = H(n,, R, Kef) © K« (11) 
10 ticket for M = H(n„, R. © K« (12) 

(v) To enable the integrity of these tickets to be verified by their respective recipients, 
generate respective verifiers fl(K^y nj and ^(K^^ nj, again using the hashing function 
provided by the MD5 encoder 58. 

(vi) In preparation for verifying the client's digital signature Sc which will subsequently 
15 be forwarded by the merchant's protocol unit M, generate two more random numbers x 

and y, both in the ranges P, i-1] and [i+1, 0,-2]^ and use them to compute a value z 
according to the relationship: 

z = {((Sc)' mod /3J((EpJ' mod /3J} (13) 

(vii) Compute two digital signatures: one signature Spc for the concatenation of the 
20 values E„ and z; and a second signature Spw for the value Ey. These signatures are 

produced by using, for example, the Digital Signature Algorithm (DSA) defined in 
Proposed Federal Information Processing Standard for Digital Signature Standard (DSS), 
Federal Register, v. 56, no, 169. 30 Aug 1991, pp. 42980-42982, to enable the values of 
E^, z and Ey to be authenticated upon recqjtion. For this purpose the unit F includes a 
25 DSA encoder 64 located within the enclosure 62 and connected to the controller 50. 

To conclude stage 104, the protocol unit F sends the following items back to the 
merchant's protocol unit M: 

Eu, z and Spc for the client's unit C; 

Ey and for the merchant's unit M; 
30 the ticket H(n„ R, K^) © K« for C; 

the ticket H(n„, R, K^) © K« for M; 

the verifiers H(K«„, ne) and H(Kc„„ nJ. 
This communication is indicated in Figure 2 by the message transfer labelled 3. 

Upon receipt of these items the merchant's protocol unit M commences stage 106 
35 of the protocol (Figure lb). First the controller 40 in this unit checks the received value 
Ey by using the associated DSA signature Sp^; for this purpose the unit M includes a DSA 
verifier 49. Next the controller derives the value of the key using the merchant's 
password P„ in the formula (Ey)^ mod /3„. With the key K^, the digital message R 
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received from the client C and the nonce n„ it generated at stage 102, the controller 40 can 
now use the MD5 encoder 48 to obtain the hashed value H(n„, R, KJ). By using an 
exclusive-OR operation of this value with the ticket K(n„, R, K^) © defined in 
equation (12), the controller 40 can determine the session key K«. The integrity of this 
5 session key is verified by obtaining the hashed value H(K^^ nj, using the MD5 encoder 
48 again, and comparing it with the corresponding hashed value sent by the protocol unit 
F. The inclusion of the nonce n„ in this check confirms that the session key has been 
freshly generated. 

If these checks are satisfactory, the controller 40 proceeds to generate a second 
10 nonce n„, for the merchant's unit M, and then obtains a new hashed value H(n„i, R, 
from the MDS encoder 48, for use in demonstrating to the client's unit C the authenticity 
of the next communication it receives from merchant's unit M. 

For this next communication, indicated by the message transfer labelled 4 in Figure 
2, the unit M sends the following items to the unit C: 
15 Ea, z and Spc (as received from the unit F); 

the ticket Hin^, R, K^f) © K« (as received from the unit F); 
the verifier H(K„, nj (as received from the unit F); 
the nonce n„i and the new hashed value H(n„,, R, K^. 

In the next stage 108 of the protocol, the controller 30 in the unit C performs 
20 several steps analogous to those just performed in the unit M: it checks the received value 
by using the associated DSA signature Spc, for which purpose it includes a DSA verifier 
39. Next the controller 30 derives the value of the key K^f using the client's password 
and with a set to the value in formula (4) above. With the key K^r, the digital message 
R and the nonce n^ it generated, the controller 30 can now use the MDS encoder 38 to 
25 obtain the hashed value H(nc, R, K^. By using an exclusive-OR operation of this value 
with the ticket K(n^, R, K^) © Is« defined in equation (11), the controller 30 can 
determine the session key K^. The integrity of this session key is verified by obtaining 
the hashed value H(K^, nj, using the MD5 encoder 38 again, and comparing it with the 
corresponding hashed value sent by the protocol unit F via the merchant's unit M. The 
30 inclusion of the nonce n^ in this check confirms that the session key K„ has been freshly 
generated. 

With this session key and the nonce n„i, the controller 30 now obtains from the 
MDS encoder 38 the hashed value H(n«i, R, K^, and compares it with the hashed value 
received from the merchant's protocol unit M. If this comparison is successful, indicating 
35 that the merchant 14 is in possession of the session key K^, the authenticity of the 
communication from the merchant 14 has been confirmed. Accordingly the client's unit 
C can proceed with authorization of the transaction. 

To this end, in the final part of stage 108 (Figure 3c). the controller 30 derives the 
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following value to enable the financial intermediary to confirm the client's signature 
undeniably: 

z, = z"^ mod 0, (14) 
where l/P^ indicates the inverse of the password Pe modulo 03^-1), derived from as 
5 described in Cryptography and Data Security by D.E. Dwming, Addison-Wesley, 1982. 

The controller 30 then obtains from the MDS encoder 38 the hashed value 
HCn^i, n^,,, R, and sends it, with the value z^ the nonce n^i which was included 
in the digital signature Sc> to the merchant's protocol unit M, as indicated by the message 
transfer labelled S in Figure 2. 
10 At stage 1 10, the controller 40 in the unit M then obtains from the MDS encoder 

48 the hashed value H(nci, Art Kcb) ^d compares it with the value received from 

the unit C. If the comparison is correct, indicating that the client 10 is also in possession 
of the session key together with the message R, the authenticity of the communication 
from the client 10 has been confirmed. Accordingly the merchant's unit M forwards the 
IS client's confirmation of the digital signature Sc by sending the items R, n^i and to the 
protocol unit F, as indicated by the message transfer labelled 6 in Figure 2. 

In the final stage 112 of the protocol, the protocol unit F, now having the nonce 
n„, obtains the hashed value H(n^i, R) ftom the MDS encoder S8, and verifies the client's 
digital signature Sc by checking whether the following relationship is satisfied: 
20 z, = {((H(n,„ R)r mod /SJ(a/ mod )3J} (15) 

If this relationship is satisfied, the signature is confirmed as being genuine, and cannot be 
repudiated (as explained below). 

This protocol establishes the following facts for the financial intermediary F: 
the authenticity of the client's signature; 
25 both the client's unit C and the merchant's unit M have correctly used their keys 

K^andK^; 

both the client's unit C and the merchant's unit M have correctly used the session 
key and they each have established that the other has correcdy used it (i.e. they have 
each authenticated the other's identity); 
30 these authentications relate to the message R; 

by sending the nonce n^ to the financial intermediary's protocol unit F, via the 
merchant's unit M, the client 10 has confirmed her agreement to the contents of the 
message R. 

The protocol accomplishes these demonstrations by means of authentication 
3S performed by the trusted intermediary 12; however, it is not necessary for the 
intermediary F to possess the passwords P^ and P„ of the client 10 and the merchant 14: 
the relevant encryption is performed without the encryption function being directly 
available to the intermediary F. Furthermore, inspection of the protocol shows that 
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nowhere is it necessary for any unit C, M or F to decrypt any value previously encrypted 
by any other unit. Thus there is no need to use a reversible encryption algorithm of a kind 
which would be subject to regulatory restrictions (typically an exclusive-OR operation is 
not regarded as falling into a restricted category). 

5 In particular the protocol involves the use of two nonces (u and v), in a nianner 

which does not require them to be communicated as such. Furthermore, the manner in 
which they are communicated (incorporated into the values and Ev) does not enable 
them to be readily discovered, and the information they protect (K^ and K^) is not 
communicated as such, although it can be obtained by parties properly possessing the 

10 appropriate passwords and P„ without those parties needing to know the values u and 
V themselves. Digital signatures Spc and Sp^ are supplied with the values and By to 
authenticate them, and are used for that purpose only. Accordingly, it is relatively easy 
and economical to implement a very secure, tamper-resistant device (i.e. the protocol unit 
F) to generate the one-time numbers u and v, compute the values E^, and Ev, and sign them 

IS digitally with the signatures Spc and Spu. 

If it is necessary to prove that the digital signature Sc did originate from the client 
10, this can be done by requesting the client to provide the result of the formula (4) for 
one hundred different numbers a. Ninety-nine of these numbers are chosen to have the 
form (a/ mod jS J, i.e. are derived from ninety-nine values of jc, so the results provided 

20 by the client 10 can be checked by performing the calculation 

((EpJ» mod /3J (16) 
If these ninety-nine results are correct, the client 10 is shown to have used her password 
Pc in obtaining them. 

The remaining value a is derived using the formula 

25 (ac' mod /3J(H(nei, R)) (17) 

where b is selected from the ranges [3. i-1] and [i+ 1 , i3c-2]. The result d provided by the 
client 10 from formula (4) is tested using the relationship 

d = [Sc((EpJ*» mod jSJl mod (18) 
If this relationship is satisfied, the digital signature Sc must have been produced using the 

30 client's password Pc- 
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CLAIMS 

1. A method for enabling authentication of an originator of a message, using a 
5 composite one-way function which enables a protected version of an input value to be 

derived by applying successively in either order two component one-way functions using two 
respective values (u, PJ, but which does not enable the input value to be readily determined 
from the protected version in combination with either of said values individually, comprising 
the steps of: 

10 a) receiving a protected version (EpJ of a password (PJ, said protected version being 
derived from a first of said component one-way functions using said password (PJ as said 
respective value; 

b) generating another value («); 

c) generating a protected version (EJ of said other value by applying a second of said 
15 component one-way functions; 

d) generating a digital signature (S^ for the protected version (EJ of said other value; 

e) applying said second component one-way function using said other value (u) to said 
protected password (EpJ to derive a ticket key (K^.f); 

0 generating a session key (K„J] 
20 g) protecting said session key (K^ with said ticket key (K^f); 

h) supplying said protected version (EJ of said other value, said digital signature (Spc) 
and said protected session key (K^J to the source of said protected password (Ej^); and 

i) thereafter destroying said other value («), said ticket key (K,f) and said session key 

25 

2. The method of claim 1, wherein said component one-way functions incorporate 
modular exponentiation. 

3. The method of claim 1 or claim 2, wherein said session key is protected with said 
30 ticket key by a bitwise exclusive-OR operation. 

4. Apparatus for enabling authentication of an originator of a message, using a 
composite one-way function which enables a protected version of an input value to be 
derived by applying successively in either order two component one-way functions using two 

35 respective values (w. PJ, but which does not enable the input value to be readily determined 
from the protected version in combination with either of said values individually, 
comprising: 

means for receiving a protected version (Ep,) of a password (1? ), said protected 
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version being derived from a first of said component one-way functions using said 
password (PJ as said respective value; 

means for generating another value (u); 

means for generating a protected version (EJ of said other value by applying a 
5 second of said component one-way functions; 

means for generating a digital signature (Spc) for the protected version (EJ of said 
other value; 

means for applying said second component one-way function using said other value 
(w) to said protected password (E^) to derive a ticket key (Kef); 
10 means for generating a session key (K^J; 

means for protecting said session key (K^ with said ticket key (Kef); 

means for supplying said protected version (EJ of said other value, said digital 
signature (Spc) and said protected session key (K^J to the source of said protected 
password (EpJ. 
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